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ABSTRACT 

A complex pervasive system is typically composed of many 
cooperating nodes, running on machines with different capa- 
bilities, and pervasively distributed across the environment. 
These systems pose several new challenges such as the need 
for the nodes to manage autonomously and dynamically in 
order to adapt to changes detected in the environment. To 
address the above issue, a number of autonomic frameworks 
has been proposed. These usually offer either predefined 
self- management policies or programmatic mechanisms for 
creating new policies at design time. From a more theoret- 
ical perspective, some works propose the adoption of pre- 
diction models as a way to anticipate the evolution of the 
system and to make timely decisions. In this context, our 
aim is to experiment with the integration of prediction mod- 
els within a specific autonomic framework in order to assess 
the feasibility of such integration in a setting where the char- 
acteristics of dynamicity, decentralization, and cooperation 
among nodes are important. We extend an existing infras- 
tructure called SelfLets in order to make it ready to host 
various prediction models that can be dynamically plugged 
and unplugged in the various component nodes, thus en- 
abling a wide range of predictions to be performed. Also, 
we show in a simple example how the system works when 
adopting a specific prediction model from the literature. 

1. INTRODUCTION 

The dramatic diffusion of portable devices and embedded 
sensors, together with the increasing wide availability of net- 
worked environments, enable a tight integration and collab- 
oration among devices and between these and more powerful 
software systems running on normal computing units. Thus, 
a complex pervasive system is typically composed by many 
cooperating nodes, running on machines with different capa- 
bilities, and pervasively distributed across the environment. 
These systems pose several new challenges such as the need 
for the nodes to manage autonomously and dynamically in 
order to adapt to changes detected in the environment as 
suggested by the autonomic computing field ITS'. The self- 
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management mechanisms that have to be put in place can 
be characterized by the following core properties: 



Dynamicity Nodes and connections can appear and disap- 
pear at runtime in an unpredictable way (node churn) [24] 
thus resulting in the fact that self-management has to 
be highly dynamic. 

Decentralization The large number of nodes involved makes 
a centralized control mechanism infeasible. Nodes must, 
instead, communicate in a peer-to-peer fashion and 
make individual decisions to avoid bottlenecks and sin- 
gle points of failure. 

Cooperation Given the number and different capabilities 
of the devices running nodes, various self-management 
elements should cooperate to share and optimize the 
use of computational resources without the interven- 
tion of an administrator. 



In order to address the above issues, a number of autonomic 
frameworks to support the development of distributed com- 
plex systems have been proposed [2] pi. They usually offer 
either predefined self-management policies or programmatic 
mechanisms for creating new policies at design time. From a 
more theoretical perspective, some works propose the adop- 
tion of prediction models [25] as a way to anticipate the 
evolution of the system and to make timely decisions. The 
prediction models available in the literature typically focus 
on specific problems to which they apply specific, often dif- 
ferent techniques. 

In this context, our aim is to experiment with the integra- 
tion of prediction models within a specific autonomic frame- 
work in order to assess the feasibility of such integration in 
a setting where the characteristics of dynamicity, decentral- 
ization, and cooperation among nodes are important. In 
particular, we base our work on the SelfLets infrastructure 
that we have presented in [13[ [6]. We extend such infras- 
tructure in order to make it ready to host various prediction 
models that can be dynamically plugged and unplugged in 
the various component nodes, thus enabling a wide range 
of predictions to be performed. Also, we show in a sim- 
ple example how the system works when adopting a specific 
prediction model from the literature. 

The remainder of this paper is organized as follows: Section 
[2] describes the problem of applying prediction models to 



autonomic systems. Section [3] presents our reference auto- 
nomic framework. Section |4] shows the contribution of this 
work to the existing system. Section [5] shows an example 
showing the capabihties of the proposed framework. Sec- 
tion in describes some relevant similar works and Section [3 
presents our conclusion and future work. 

2. RUNTIME PREDICTION MODELS FOR 
SELF-ORGANIZING SYSTEMS 

The Self-* properties envisioned by the autonomic comput- 
ing Manifesto [I^ represent high-level objectives that will 
be gradually achieved following an evolutionary approach 
rather than a revolutionary one [15]. Much of the cur- 
rent research focuses in developing models able to describe 
the characteristics of systems enhanced with autonomic fea- 
tures. In this context, the adoption of prediction models 
represents a valid direction to achieve the Self-* properties; 
in fact, having a good estimate of the future internal state 
and external world allows the system to adjust the current 
behavior based on self-optimization and self-healing criteria. 

In the literature a large number of prediction techniques 
ranging from time-series analysis [t] to machine-learning [m] 
are available. The choice of the most appropriate algorithm 
depends at least on two factors [25] : the predicted time hori- 
zon (long-term vs. short-term) and the type of data (e.g., 
numerical, Boolean). However our efforts do not concentrate 
on the development of a new algorithm. Instead, we focus on 
the development of a framework able to host different tech- 
niques without being strictly tied to a particular one. This 
approach has the advantage of being flexible and to repre- 
sent a useful testbed for studying the impact of predictive 
algorithms on the self-* properties. 

When applying prediction models to autonomic systems im- 
portant points to be investigated concern the way the in- 
formation used by prediction algorithms are collected and 
handled, where the prediction algorithm runs, and where 
the subsequent decisions are made. When the system is dis- 
tributed, we can easily imagine that pieces of information are 
spread across all nodes. In this situation, it is not always fea- 
sible and efficient to convey all such pieces to a single node 
that runs the prediction algorithm, as it is usually assumed. 
On the contrary, it may be more convenient to keep infor- 
mation local to each node (or meaningful subset of nodes) 
and to perform predictions in each node. Of course, in this 
case, as each element has an incomplete view of the system 
state, the task of producing valid predictions becomes more 
challenging and may produce non-optimal results. 

Estimated results obtained from prediction mechanisms are 
then employed by policies which regulate the specific reac- 
tion; again, the decision on which reaction to apply can be 
made in a centralized or decentralized way. 

While most of the approaches in the literature take a central- 
ized perspective, we implement our framework in order to 
support also the local perspective with the aim of comparing 
the two approaches and trying to identify the circumstances 
under which the local one produces good results. 

3. THE SELFLET APPROACH 



The autonomic framework that we use as a starting point 
for our work is presented in more details in [13[ p] and 
is based on an autonomic infrastructure and architectural 
model called Self Lets. 

According to the Self Lets model a software system is com- 
posed of various autonomous elements, each of which is a 
Self Let. Every Self Let is defined in terms of: 



• A main goal that defines the aim for which it has been 
developed. 

• A main behavior that represents a possible implemen- 
tation to fulfill the main goal. It is continuously ex- 
ecuted by the component and may depend on some 
external services offered either by the same SelfLet 
or by other Self Lets. 

• A number of offered services and the corresponding 
implementation (behaviors) that can be executed in 
parallel with the main behavior and are triggered on 
demand by the component itself or by its neighbors 
through a service call. 

• Some autonomic policies that define reactions to ab- 
normal situations that can occur during the life-time 
of the SelfLet. The reactions include the possibility 
of changing the main behavior, disabling/enabling the 
execution of the other behaviors, disabling/enabling 
the interaction with some neighbors, etc. 



In our approach, services can be offered in different ways. A 
SelfLet can run a Service and return the result to the caller: 
in this case the service is offered in a "Can Do" way. Alter- 
natively, the SelfLet can be available to teach the service, 
so that the requester is able to execute the service by itself 
from then on. We call this the "Can Teach" way. A Self- 
Let can offer a service even if it does not know it directly, 
by using the "Knows Who Can Do" and "Knows Who Can 
Teach" ways: in this case, the SelfLet will give the requester 
information about SelfLets able to either offer the service 
or provide directions for the execution of the service. Each 
combination of these "offer modes" is allowed. 

SelfLets can respond to requests for a specific service call or 
spontaneously advertise their offered services to inform the 
other SelfLets about them. Indeed, when issuing a service 
request, a SelfLet can specify the offer mode it would prefer. 
The preference it expresses depends in most cases on its 
current policy and on the actual need for that service. 

Each SelfLet maintains a list of known providers for each 
service it requires (and cannot offer itself). Then, when 
a need for such a service arises, the SelfLet selects one of 
these providers according to a given policy, and directly asks 
it for the service. The SelfLets in a network cooperate to 
keep such lists always up-to-date with information about the 
availability of providers. 

The SelfLet offers to policies writers a list of actions that 
enable the transformation of several aspects of the SelfLet 
itself. These methods are the way the decisions made by the 
policies are put in action to adapt to a changed situation. 



The actions offered in the current implementation include, 
besides the methods related to service execution: 



• change the way a service is offered or asked. In par- 
ticular, it could be offered or asked in a teach, do, or 
know who can do mode, or in all modes at the same 
time; 

• install a new service within the Self Let; 

• install new abilities; 

• modify a given behavior, directly deleting and replac- 
ing its component states and transitions. 



Designers program the behaviors using UML state diagrams 
(with some restrictions that have been introduced to formal- 
ize their semantics) and the autonomic policies using a rule 
language called Drools 1 . Figure IT] shows an example of a 
behavior taken from a Self Let managing consumption of en- 
ergy in a home environment. In the initial state the current 
level of energy consumption is monitored and, depending on 
this value, three things may happen. The conditions over the 
arcs define what the next state is by comparing the sensed 
energy value to an internal threshold. If the consumption is 
normal then no action is taken; if the sensed value is dan- 
gerously near to a maximum threshold then a request for 
more energy capacity is issued to the other neighbor Self- 
Lets; finally, if the current consumption is higher than the 
threshold then the Self Let goes into a wait state where the 
energy provisioning to the corresponding home is blocked. 
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Figure 2: The internal architecture of a SelfLet. 



this second case, asks the Negotiation Manager to retrieve 
the Service and negotiate with the corresponding SelfLet a 
proper offer mode. 

The Negotiation Manager communicates with other SelfLets 
in the network by means of the Message Handler. The un- 
derlying communication framework used to enable the com- 
munication among SelfLets is REDS 12 , that adopts the 



publish/subscribe approach. This communication paradigm 
does not require SelfLets to know each other's identity: a 
relevant advantage in large-scale, self-managing, distributed 
systems. 

The Internal Knowledge is composed of four parts: Knowl- 
edge Base, which can be used to store and retrieve any kind 
of information needed by any of the SelfLet components; 
Service Repository, which lists Services the SelfLet can offer 
(to itself or to other SelfLets); Behaviors Repository, which 
contains all the StateChart the SelfLet is able to run; At- 
tribute Repository, which stores descriptions about the Self- 
Let. 



Figure 1: Main behavior of the Electricity SelfLet. 

The heart of the SelfLet architecture (see Figure [2| is the 
Autonomic Manager, which is responsible for the evolution 
of a SelfLet during its lifetime. The Autonomic Manager 
manages the SelfLet behavior according to the set of Au- 
tonomic Policies it has installed. This set can evolve over 
time. The Autonomic Manager is implemented exploiting 
Drools [l], a Java Production Rule System. The well-known 
features of the Production Rule Systems, along with the ad- 
vanced nature of the Drools language, allow the SelfLet pro- 
grammers to write sophisticated autonomic policies, using a 
simple, declarative style. 

The Behavior Manager controls the execution of the Self- 
Let's behavior. The behavior run by the SelfLet to achieve 
its Goal, indeed, contains calls either to local or remote ser- 
vices. In the case a request for a service arises, the Auto- 
nomic Manager triggers the execution of a rule that veri- 
fies whether the service is locally available or not, and, in 



The Ability Execution Environment is in charge of executing 
simple Java operations, the Abilities, than can be activated 
as part of behaviors for performing specific low-level tasks. 

The communication internal to the SelfLet follows a pub- 
lish/subscribe approach. All architectural components are 
connected to a Dispatcher that is in charge of receiving 
subscriptions for events and event publications. It asyn- 
chronously deliver all published events to those components 
that have subscribed to them. The same publish/subscribe 
paradigm is adopted for the communication among Self- 
Lets. In this second case, in order to guarantee scalability, a 
distributed and optimized dispatching system is adopted 



12 



The SelfLets approach has been implemented both on a 
full fledged Java platform and on wireless sensors running 
the TinyOS operating system and adopting the NesC pro- 
gramming language. This second implementation, known as 
TinySelfLet, implements a smaller set of functionalities due 
to the physical constraints of the devices and is currently 
being consolidated |22|. 



4. INTEGRATING PREDICTION MODELS 
INTO THE SELFLET APPROACH 

As we have already mentioned, we extend the Self Let ar- 
chitecture by incorporating prediction models that allow the 
Self Lets autonomic policies to be activated in a more timely 
way. 

The context in which Self Lets are used is a distributed one 
with large number of nodes. Due to this requisite, we de- 
cided to adopt a completely decentralized approach in which 
each node can produce predictions and actuate them inde- 
pendently from other nodes. 

Any prediction model bases its forecasts on what happened 
in the past within a certain (sub)system. In our specific 
case we look at the events that are produced within a Self- 
Let and at those that arrive to that Self Let from the ex- 
ternal environment. These events are received as input by 
prediction models that, in turn, generate new events that 
represent the forecast. Such forecast is then received by the 
Autonomic Manager and can activate a proper autonomic 
policy. The framework allows for two degrees of freedom: 
the first is constituted by the choice of the prediction model 
to adopt and second one is represented by the definition 
of the autonomic policy that implements the reaction to a 
prediction. 

Algorithms implementing new prediction models can be in- 
tegrated into a Self Let following a plugin approach. Each 
implementation should inherit from a specific Java class hi- 
erarchy, PredictionModel, and should be accompanied by a 
descriptor where the events needed for the prediction model 
to work are specified. The same descriptor includes also 
the events that are generated by the same implementation 
and that will be the inputs to trigger some autonomic policy. 
The autonomic policy is defined as a set of Drools production 
rules and it is installed in the Autonomic Manager according 
to the mechanisms already defined as part of a Self Let. 

Prediction model implementations are operated by the Pre- 
diction Manager that is in charge of their correct installa- 
tion and of providing them with the needed events. Simi- 
larly to what happens in the Eclipse framework, at the time 
the SelfLet is deployed, the Prediction Manager looks for 
prediction model implementations to install and checks the 
corresponding descriptors. Then it connects to the Self- 
Let Dispatcher from which it receives all events being circu- 
lated in the SelfLet. When it receives an event of interest 
of some prediction model implementation, then it forwards 
such event to it. When a prediction model implementation 
produces a forecast, it forwards it to the Prediction Man- 
ager that, in turn, publishes it to the Dispatcher. If any 
autonomic policy exists that is triggered by that event, then 
this receives it and executes the corresponding reaction. The 
prediction subsystem resulting from the development of Pre- 
diction Manager and prediction model implementations is 
highlighted in Figure [2] 



5. EXAMPLE AND RESULTS 

We performed a preliminary validation of our framework 
with the objective to evaluate that the functionality of the 
prediction framework is correct. The validation of the pro- 



posed framework consisted in the following main stages: 1) 
the development of a simple example involving two types of 
cooperating Self Lets; 2) the individuation of a possible au- 
tonomic behavior that could optimize the execution of the 
Self Lets pair; 3) the implementation of the corresponding 
prediction model and autonomic policy, 4) the execution of 
the system and the collection of results. 

5.1 The example 

The example that we have adopted for the evaluation shows 
a very simple application logic. The reason for this is that 
we wanted to focus our attention on the prediction and re- 
configuration aspects and not on a specific application logic. 
The system configuration is composed of two Self Lets: Si 
and ^2. Si needs periodically a service (Service 1) that 
is offered by 82- In turn, 5*2 offers three services, Service 
1, Service 2, and Service 3 that are implemented by the 
three basic behaviors shown in Figure [3] Looking at the 
behaviors, the reader can notice that, in order to execute 
Service 1, 52 needs to call also Service 2 and Service 3. 
All services are initially offered in the "Can Do" mode. 
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Figure 3: The behaviors installed in S2. 

5.2 Expected autonomic behavior, prediction 
model, and autonomic policies 

Even though the example described in the previous section 
is quite simple, there is at least one element that could intro- 
duce an optimization in the execution of the system. This 
is the idea of forcing the learning of frequently requested 
services so that their future invocations will be directly car- 
ried out locally instead of remotely. This allows a saving of 
network messages and brings computation where it is more 
likely to be needed. In our example such optimization could 
be possibly achieved by having S2 teaching Service 1 to Si 
with the aim of limiting the number of requests that reach 
S2 from Si. 

In order to achieve this objective, we defined a prediction 
model that, based on the history of service requests arriving 
to a certain SelfLet from the other SelfLets, can forecast 
a certain trend of requests and therefore can trigger the ex- 
ecution of an autonomic policy that enables the service to 
be requested in a "Can Teach" mode. The prediction model 
we have chosen for the experiment is based on the simple 
assumption that if a certain service request is executed fre- 
quently in a certain time window in the immediate past, then 
it will be very likely reiterated again in the future. Thus, the 
prediction model implementation requires to know all the 



events that concern outgoing service requests and produces 
an event that identifies the service that should be acquired 
by the Self Let. 

Many algorithms are available in the literature to identify 
frequent events in a data stream [8| |11[ |10|; we chose to 



implement the algorithm proposed by Metwally et Al. 21 
due to its tight error guarantees and minimal space require- 
ments, desirable property on small devices. To be considered 
frequent, an event must satisfy the following conditions on 
the minimum number of events and on the support: 



NumEventSx > Minimum Occurrences 



(1) 



„ NumEventSx „ „, , , , /„n 

bupportx ~ i^ > rrequencvl hreshoia (2) 

^^ NumTotEvents - ^^ « w 



In our example, such equations are applied to the events 
representing service requests. The result produced by the 
prediction model implementation is a new event containing 
information about the most frequent service request and its 
support. Such event triggers the policy described in pseu- 
docode in Listing [l] 



rule "change service ask mode" 
when 

"Requests for a remote service become frequent" 
then 

"Ask the service in teach mode" 
end 



Listing 1: Autonomic pohcy 

5.3 Results 

The dynamic behavior we expect to see in the example can 
be divided in three stages: 



1. The first stage sees Si asking for service Service 1. As 
requests for such remote service keep increasing, there 
will be a point in time when the service is considered 
frequent. As a consequence, the service is asked in 
teach mode and the behavior implementing it becomes 
also available at Si. However the subservices needed 
by the just installed behavior are not transferred. 

2. The second stage sees Service 1 locally executed by 
Si. Since the two subservices needed by the behav- 
ior are not located within Si, two broadcast service 
requests are sent. These will be possibly replied by 
S2 . Now things seems getting worse since to complete 
the service, two messages need to be sent (i.e. one for 
Service 2 and one for Service 3). However this is a 
temporary situation, in fact, if Si will keep calling the 
other two services, these eventually will be recognized 
as frequent services and a request for them in teach 
mode will be issued. 

3. In the last step the system converges into a stable situ- 
ation in which the needed services are all locally avail- 
able for each node. At this point no more messages, 
asking it to achieve a remote service, are sent to S2. 



The described example has been ran for different time inter- 
vals, monitoring the number of times a service has been exe- 
cuted; in order to evaluate the results, the same experiment 
has been executed also by disabling the self-optimization 
policy. Table [1] shows the results obtained for different time 



Experiment 
duration 

(sec) 


Goals 

executed 

by Si 


Goals 

executed 

bySa 


Total number 
of messages 
exchanged 


Without self-optimizing policy | 


180 


78 


87 


78 


300 


132 


146 


160 


540 


240 


240 


242 


900 


403 


403 


403 


With self-optimizing policy | 


180 


78 


87 


79 


300 


128 


145 


160 


540 


232 


265 


311 


900 


410 


444 


311 



Table 1: The results obtained in the example exper- 
iment. 

intervals; it reports the cumulative number of times the ser- 
vice has been requested in each Self Let and the total num- 
ber of messages exchanged within the system due to the 
request for remote services. It is possible to notice that af- 
ter about 540 seconds, the system with the autonomic pol- 
icy reaches a stability and no more messages are exchanged 
between SelfLets. Conversely, in the system without the 
autonomic policy. Si continues to forward requests to S2 
thus having a linear increase of messages with time. It is 
important to notice that at 540 seconds, the configuration 
without the autonomic policy sends less messages than the 
other configuration; this behavior is expected because after 
having learnt Service 1, Si needs to send two remote re- 
quests for the two subservices. However, this is a transient 
phase, since the two subservices will be later on recognized 
as frequent and thus learnt by Si. 

6. RELATED WORK 

Several research groups are being investigating the various 
areas of autonomic computing and are building frameworks 
to support the development of systems showing some self* 
property. Besides the seminal Manifesto [16], IBM con- 
tributed to the Autonomic Computing research field with 
a reference architectural model [T7|; this model represents 
autonomic computing systems as a layered architecture to- 
gether with an autonomic control loop. A different approach 
to the autonomic computing is the one known as emergence; 
it takes inspiration from the biological world which contains 
many examples of successful distributed systems. More pre- 
cisely, the emergence refers to complex behaviors emerging 
from the interaction of many elements performing very sim- 
ple actions. Reference work for this approach are [4] and 
[20| . To the best of our knowledge no work explicitly faces 
the problem of introducing a framework for prediction mod- 
els into an autonomic platform. 

Referring to more theoretical approaches, an important part 
of the work performed on prediction models regards the 
management of Web systems [9|[3]. These works study the 



issues involved in creating a representative view of a web sys- 
tem by detecting significant and non-transient load changes. 
A similar work has been carried out in [23] in which peri- 
ods of high utilization or poor performance are predicted 
using data mining and machine learning techniques. The 
study aims at optimizing the resources assignment and the 
computation of opportunistic job scheduling by using auto- 
regressive methods, multivariate regression methods and bayesian 
network classifiers. In [19] the authors present an approach 
to obtain response time predictions regarding a web applica- 
tion. However the work does not specify how a component 
acting as our autonomic manager should use the results of 
prediction which is left as future work. 

7. CONCLUSIONS AND LESSON LEARNT 

In this paper we described the extension of an existing au- 
tonomic framework with prediction models. We decided to 
design a flexible architecture in which different prediction 
models can be hosted. This has been achieved following a 
plugin approach. In order to validate the work, we imple- 
mented a prediction model which computes frequency es- 
timates of service requests issued by Self Lets. The reac- 
tion to the predictions is described by a policy optimizing 
the location of more frequently requested services within the 
system. The algorithm that allows a Self Let to identify fre- 
quent service calls is simple on purpose as this way it can be 
executed on the fly any time it is needed. The proposed au- 
tonomic feature has been tested with a simple example; the 
results showed that after an initial time interval the system 
converges toward a stable configuration in which frequently 
executed remote services are taught to the SelfLets that 
invoke them. The tests have also highlighted some critical 
aspect. In particular, the fact that the transfer of a behav- 
ior could determine a cascade effect in which many other 
services are transfered may introduce some dangerous recur- 
sion. This aspect could be handled by evaluating in advance 
the consequences of moving a service to a Self Let. How to 
handle this aspect as well as the identification and incorpo- 
ration of other prediction models and autonomic policies is 
the subject of our ongoing research. 
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